SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Behavior tree</title>

</head>

Behavior tree

</h1>

</header>

/* start https://en.wikipedia.org/ */

.mw-parser-output .hatnote{font-style:italic}.mw-parser-output div.hatnote{padding-left:1.6em;margin-bottom:0.5em}.mw-parser-output .hatnote i{font-style:normal}.mw-parser-output .hatnote+link+.hatnote{margin-top:-0.5em}@media print{body.ns-0 .mw-parser-output .hatnote{display:none!important}}

/* end https://en.wikipedia.org/ */

</style><div role="note" class="hatnote navigation-not-searchable">This article is about behavior trees for requirement handling. For another use, see <a href="Behavior_tree_(artificial_intelligence%2C_robotics_and_control)" title="Behavior tree (artificial intelligence, robotics and control)">Behavior tree (artificial intelligence, robotics and control)</a>.</div>

A behavior tree is a structured visual <a href="Modeling" class="mw-redirect" title="Modeling">modeling</a> technique used in <a href="Systems_engineering" title="Systems engineering">systems engineering</a> and <a href="Software_engineering" title="Software engineering">software engineering</a> to represent system behavior. It utilizes a hierarchical tree diagram composed of <a href="Node_(computer_science)" title="Node (computer science)">nodes</a> and connectors to illustrate control flow and system actions. By replacing ambiguous <a href="Natural_language" title="Natural language">natural language</a> descriptions with standardized visual elements—such as boxes, arrows, and standard symbols—behavior trees improve clarity, reduce misinterpretation, and enhance understanding of complex systems.<a href="#cite_note-1">[1]</a>

<div class="mw-heading mw-heading2"><h2 id="Overview">Overview</h2></div>

The extensive amount of detail involved in describing the numerous requirements of a large-scale system using natural language can lead to <a href="Short-term_memory" title="Short-term memory">short-term memory</a> overload,<a href="#cite_note-dromey07EngLgeScale-2">[2]</a><a href="#cite_note-raytheonSysResearch-3">[3]</a> hindering a comprehensive understanding of the system's needs.<a href="#cite_note-raytheonAustJoint-4">[4]</a> <a href="Natural_language" title="Natural language">Natural language</a> often introduces ambiguities, aliases, inconsistencies, redundancies, and incomplete information to concepts.<a href="#cite_note-dromey03K1-Dromey-5">[5]</a> This creates uncertainty and over-complicates systems.

The behavior tree representation attempts to eliminate uncertainty by limiting vocabulary to the original requirements. Large requirement sets may require the help of a composition tree<a href="#cite_note-compositionTree-6">[6]</a> representation that resolves aliases and other vocabulary problems in a prior step. The aim is to produce a deep, accurate, and holistic representation of system needs<a href="#cite_note-dromey07EngLgeScale-2">[2]</a> that can be understood by all readers (often <a href="Project_stakeholder" title="Project stakeholder">stakeholders</a>). Since the behavior tree notation uses <a href="Semantics_of_programming_languages" class="mw-redirect" title="Semantics of programming languages">formal semantics</a>, it can serve as input for further processing, such as making an <a href="Executable" title="Executable">executable</a> for a given set of requirements.

<div class="mw-heading mw-heading3"><h3 id="Behavior_tree_forms">Behavior tree forms</h3></div>

Both single and integrated (composite) behavior tree forms are important in applying behavior trees in <a href="Systems_engineering" title="Systems engineering">systems</a> and <a href="Software_engineering" title="Software engineering">software engineering</a>.

<ul><li>Requirement behavior trees (RBT): Initially, individual requirement behavior trees are constructed to capture all behavioral fragments from each natural language requirement, using a rigorous translation process that preserves both intent and vocabulary. The translation process can uncover a range of defects in original <a href="Natural_language" title="Natural language">natural language</a> requirements.</li>

<li>Integrated behavior trees (IBT): Because a set of requirements imply the integrated behavior of a system, all the individual requirement behavior trees can be composed to construct an integrated behavior tree that provides a single holistic view of the emergent integrated behavior of the system. This enables the construction of the system's integrated behavior from its requirements.<a href="#cite_note-winters-7">[7]</a> An analogy to help describe this process is the transition from a randomly arranged set of <a href="Jigsaw_puzzle" title="Jigsaw puzzle">jigsaw puzzle</a> pieces to putting each of the pieces in its appropriate place. When this happens, each piece of information is placed in its intended context and their collective emergent properties become clear.</li></ul>

Having all the requirements converted to behavior trees (RBT) is similar to having all the pieces for a <a href="Jigsaw_puzzle" title="Jigsaw puzzle">jigsaw puzzle</a> randomly spread out on a table – until all the pieces are connected, the emergent picture remains unclear, and it is uncertain whether any pieces are missing or don’t fit. Constructing an integrated behavior tree (IBT) reveals emergent behavior and missing pieces.<a href="#cite_note-dromey06FormalizingTrans-8">[8]</a><a href="#cite_note-dromey03K1-Dromey-5">[5]</a>

<div class="mw-heading mw-heading3"><h3 id="Behavior_engineering_process">Behavior engineering process</h3></div>

Critical aspects of behavior engineering representation and process are listed below.

Representation:

<ul><li>The composition tree's role in the overall process is to provide a means to overcome the imperfect knowledge associated with the large set of requirements for a system.</li></ul>

Process:

<ul><li>Behavior engineering uses behavior trees to control complexity while growing a shared understanding of a complex system.</li></ul>

<ul><li>A shared holistic understanding of a complex system integrates requirements to show its implied emergent behavior.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="History">History</h2></div>

Behavior trees and the concepts for their application in <a href="Systems_engineering" title="Systems engineering">systems</a> and <a href="Software_engineering" title="Software engineering">software engineering</a> were originally developed by Geoff Dromey.<a href="#cite_note-dromey06FormalizingTrans-8">[8]</a><a href="#cite_note-dromey03K1-Dromey-5">[5]</a><a href="#cite_note-9">[9]</a><a href="#cite_note-10">[10]</a> The first publication of some of the key ideas were in 2001.<a href="#cite_note-11">[11]</a> Early publications on this work used the terms "genetic software engineering" and "genetic design" to describe the application of behavior trees. The reason for originally using the word "genetic" was because sets of genes, sets of jigsaw puzzle pieces, and sets of requirements, when represented as behavior trees, all appear to share several key properties:

<ul><li>They contained enough information as a set to allow them to be composed – with behavior trees, this allows a system to be built out of its requirements.</li>

<li>The order in which the pieces were put together was not important – with requirements, this aids in coping with complexity.</li>

<li>When all the members of the set were put together, the resulting integrated entity exhibited a set of important <a href="Emergent_properties" class="mw-redirect" title="Emergent properties">emergent properties</a>.</li></ul>

For behavior trees, important emergent properties include:

<ul><li>The integrated behavior of the system is implied by the requirements.</li>

<li>The coherent behavior of each component is referred to in the requirements.</li></ul>

These genetic parallels, in another context, were originally spelled out by Adrian Woolfson.<a href="#cite_note-12">[12]</a>

Further weight for use of the term "genetic" came from eighteenth-century thinker <a href="Giambattista_Vico" title="Giambattista Vico">Giambattista Vico</a>, who said, "To understand something, and not merely be able to describe it, or analyze it into its component parts, is to understand how it came into being – its genesis, its growth … true understanding is always genetic".<a href="#cite_note-Vico-13">[13]</a> Despite these legitimate genetic parallels, it was felt that this emphasis led to confusion with the concept of <a href="Genetic_algorithms" class="mw-redirect" title="Genetic algorithms">genetic algorithms</a>. As a result, the term behavior engineering was introduced to describe the processes that exploit behavior trees to construct systems. The term "behavior engineering" has previously been used in a specialized area of <a href="Artificial_intelligence" title="Artificial intelligence">artificial intelligence</a> – robotics research. The present use embraces a much broader, rigorous formalization and the integration of large sets of behavioral and compositional requirements that are required to model large-scale systems.

Since the behavior tree notation was originally conceived, several people from the Dependable Complex Computer-based Systems Group (DCCS – a joint <a href="University_of_Queensland" title="University of Queensland">University of Queensland</a>, <a href="Griffith_University" title="Griffith University">Griffith University</a> research group) have made important contributions to the evolution and refinement of the behavior tree notation and usage.<a href="#cite_note-14">[14]</a>

Probabilistic timed behavior trees have been developed by researchers such as Rob Colvin, Lars Grunske, and Kirsten Winter of the DCCS, so that reliability, performance, and other dependability properties could be expressed.<a href="#cite_note-probTimedBTs-15">[15]</a>

<div class="mw-heading mw-heading2"><h2 id="Key_concepts">Key concepts</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Behavior_tree_notation">Behavior tree notation</h3></div>

A behavior tree is used to formally represent the fragment of behavior in each requirement. In general, behavior for a large-scale system, where <a href="Concurrency_(computer_science)" title="Concurrency (computer science)">concurrency</a> is admitted, appears abstractly as a set of <a href="Communicating_sequential_processes" title="Communicating sequential processes">communicating sequential processes</a>. The behavior tree notation captures these composed component-states and represents them as a tree-like form.

Behavior is expressed in terms of components realizing states and components creating and breaking relations. Using the logic and graphic forms of conventions found in <a href="Programming_languages" class="mw-redirect" title="Programming languages">programming languages</a>, components can support actions, composition, events, control-flow, data-flow, and threads.<a href="#cite_note-dromey03K1-Dromey-5">[5]</a>

Traceability tags (see Section 1.2 of behavior tree notation<a href="#cite_note-BTNotation-16">[16]</a>) in behavior tree nodes link the formal representation to the corresponding <a href="Natural_language" title="Natural language">natural language</a> requirement. Behavior trees accurately capture behavior expressed in the natural language representation of functional requirements. Requirement behavior trees strictly use the vocabulary of the natural language requirements but use graphical forms for behavior composition to remove the risk of ambiguity. By doing this, they provide a direct and clearly traceable relationship between what is expressed in the natural language representation and its <a href="Formal_specification" title="Formal specification">formal specification</a>.<a href="#cite_note-geneticDesign05-17">[17]</a>

A basis of the notation is that behavior is always associated with some component. Component-states, which represent nodes of behavior, are composed sequentially or concurrently to construct a behavior tree that represents the behavior expressed in the natural language requirements. A behavior tree with leaf nodes may revert (symbolized by adding the <a href="Caret" title="Caret">caret</a> operator "^") to an ancestor node to repeat behavior or start a new thread (symbolized by two carets "^^").

A behavior tree specifies state changes in components, how data and control are passed between components, and how <a href="Threads_(computer_science)" class="mw-redirect" title="Threads (computer science)">threads</a> interact. There are constructs for creating and breaking relations. There are also constructs for setting and testing <a href="State_(computer_science)" title="State (computer science)">states</a> of components, as well as mechanisms for <a href="Inter-process_communication" title="Inter-process communication">inter-process communication</a> that include <a href="Message_passing" title="Message passing">message passing</a> (events), shared variable blocking, and <a href="Synchronization_(computer_science)" title="Synchronization (computer science)">synchronization</a>.

For a complete reference to behavior tree notation, see Behavior Tree Notation v1.0 (2007).<a href="#cite_note-BTNotation-16">[16]</a>

<div class="mw-heading mw-heading3"><h3 id="Semantics">Semantics</h3></div>

The <a href="Semantics_of_programming_languages" class="mw-redirect" title="Semantics of programming languages">formal semantics</a> of behavior trees is given via a <a href="Process_algebra" class="mw-redirect" title="Process algebra">process algebra</a> and its <a href="Operational_semantics" title="Operational semantics">operational semantics</a>.<a href="#cite_note-colvinHayesNotation-18">[18]</a> The semantics have been used as the basis for developing <a href="Simulation" title="Simulation">simulation</a>, <a href="Model_checking" title="Model checking">model checking</a>, and <a href="Failure_mode_and_effects_analysis" title="Failure mode and effects analysis">failure modes and effects analysis</a>.<a href="#cite_note-colvinHayesNotation-18">[18]</a><a href="#cite_note-automatedFailEffect05-19">[19]</a><a href="#cite_note-integratingSafety05-20">[20]</a>

<div class="mw-heading mw-heading3"><h3 id="Requirements_translation">Requirements translation</h3></div>

Requirements translation is the vehicle used to cross the informal-barrier. Consider the process of translation for requirement R1 below. The first tasks are to identify the components (bold), identify the behaviors (underlined), and identify indicators of the order (italics) in which behaviors take place. The corresponding behavior tree can then be constructed.

What is clear from the outcome of this process is that, apart from pronouns, definite articles, etc., essentially all the words in the sentences that contribute to the behavior they describe have been accounted for and used.

<div class="mw-heading mw-heading3"><h3 id="Requirement_integration">Requirement integration</h3></div>

Once the set of requirements is formalized as individual requirement behavior trees, two joint properties of systems and requirements need to be exploited to proceed with composing the integrated behavior tree:

<ul><li>In general, a fragment of behavior described by a requirement always has an associated precondition that must be satisfied before the behavior can occur. This precondition may or may not be explicitly stated in the requirement.</li>

<li>If the requirement is really part of the system, then some other requirement in the set must establish the precondition needed in (1).</li></ul>

For requirements represented as behavior trees, this amounts to finding where the root node of one tree occurs in some other behavior tree and integrating the two trees at that node.

The example below illustrates requirement integration for two requirements, R1 and R3. In other words, it shows how these two requirements interact.

<div class="mw-heading mw-heading3"><h3 id="Operations_on_integrated_behavior_trees">Operations on integrated behavior trees</h3></div>

Once an integrated behavior tree has been composed, there are a number of important operations that can be performed upon it.

<div class="mw-heading mw-heading4"><h4 id="Inspection:_defect_detection_and_correction">Inspection: defect detection and correction</h4></div>

In general, many defects become much more visible when there is an integrated view of the requirements<a href="#cite_note-dromey07EngLgeScale-2">[2]</a> and each requirement has been placed in the behavior context where it needs to execute. For example, it is much easier to tell whether a set of conditions or events emanating from a node is complete and consistent. The traceability tags<a href="#cite_note-BTNotation-16">[16]</a> also make it easy to refer back to the original natural-language requirements. There is also the potential to automate a number of defect and consistency checks on an integrated behavior tree.<a href="#cite_note-buildEnv04-21">[21]</a>

When all defects have been corrected and the IBT is logically consistent and complete, it becomes a model behavior tree (MBT), which serves as a <a href="Formal_specification" title="Formal specification">formal specification</a> for the system's behavior that has been constructed out of the original requirements. This is the clearly defined stopping point for the analysis phase. With other <a href="Modeling_languages" class="mw-redirect" title="Modeling languages">modeling notations</a> and methods (i.e. <a href="Unified_Modeling_Language" title="Unified Modeling Language">UML</a>), it is less clear-cut when modelling can stop.<a href="#cite_note-shuttle04-22">[22]</a> In some cases, parts of a model behavior tree may need to be transformed to make the specification <a href="Executable" title="Executable">executable</a>. Once an MBT has been made executable, it is possible to carry out a number of other dependability checks.

<div class="mw-heading mw-heading4"><h4 id="Simulation">Simulation</h4></div>

A model behavior tree can be readily simulated to explore the dynamic properties of the system. Both a symbolic tool and a graphics tool have been constructed to support these activities.<a href="#cite_note-Integrare07-23">[23]</a><a href="#cite_note-realTimeColloab06-24">[24]</a>

<div class="mw-heading mw-heading4"><h4 id="Model_checking">Model checking</h4></div>

A translator has been written to convert a model behavior tree into the "actions systems" language. This input can then be fed into the SAL Model checker<a href="#cite_note-SAL2-25">[25]</a><a href="#cite_note-26">[26]</a> to allow checks to be made as to whether certain safety and security properties are satisfied.<a href="#cite_note-automatedFailEffect05-19">[19]</a><a href="#cite_note-embeddedSys05-27">[27]</a>

<div class="mw-heading mw-heading4"><h4 id="Failure_mode_and_effects_analysis_(FMEA)">Failure mode and effects analysis (FMEA)</h4></div>

<a href="Model_checking" title="Model checking">Model checking</a> has often been applied to system models to check that hazardous states can’t be reached during normal operation of the system.<a href="#cite_note-probabilistic07-28">[28]</a> It is possible to combine model-checking with behavior trees to provide automated support for <a href="Failure_mode_and_effects_analysis" title="Failure mode and effects analysis">failure mode and effects analysis</a> (FMEA).<a href="#cite_note-automatedFailEffect05-19">[19]</a> The advantage of using behavior trees for this purpose is that they allow the <a href="Formal_method" class="mw-redirect" title="Formal method">formal method</a> aspects of the approach to be hidden from non-expert users.

<div class="mw-heading mw-heading4"><h4 id="Requirement_changes">Requirement changes</h4></div>

The ideal sought when responding to a change in the <a href="Functional_requirements" class="mw-redirect" title="Functional requirements">functional requirements</a> for a system is that it can be quickly determined:

<ul><li>where to make the change,</li>

<li>how the change affects the architecture of the existing system,</li>

<li>which components of the system are affected by the change, and,</li>

<li>what behavioral changes will need to be made to the components (and their interfaces) that are affected by the change of requirements.<a href="#cite_note-dromey07FormalPath-29">[29]</a></li></ul>

Because a system is likely to undergo many changes over its service life, it is necessary to record, manage, and optimize its evolution driven by these changes.

A traceability model, which uses behavior trees as a formal notation to represent functional requirements, reveals change impacts on different types of design constructs (documents) caused by the changes of the requirements.<a href="#cite_note-30">[30]</a> The model introduces the concept of evolutionary design documents that record the change history of the designs. From these documents, any version of a design document, as well as the difference between any two versions, can be retrieved. An important advantage of this model is that automated tools can support a major part of the procedure to generate these evolutionary design documents.<a href="#cite_note-buildEnv04-21">[21]</a>

<div class="mw-heading mw-heading4"><h4 id="Code_generation_and_execution">Code generation and execution</h4></div>

The behavior tree representation of the integrated behavior of the system offers several important advantages as an executable model. It clearly separates the tasks of component integration from the task of individual component implementation. The integrated system behavior resulting from requirement integration can serve as a foundation for design decisions. The result is a design behavior tree (DBT):<a href="#cite_note-dromey03K1-Dromey-5">[5]</a> an executable multi-thread component integration specification that has been built out of the original requirements.

Behavior tree models are executed in a virtual machine called the behavior run-time environment (BRE). The BRE links together <a href="Component-based_software_engineering#Software_component" title="Component-based software engineering">components</a> using <a href="Middleware" title="Middleware">middleware</a>,<a href="#cite_note-middleware-31">[31]</a> allowing components to be independent programs written in one of several languages that can be executed in a <a href="Distributed_computing" title="Distributed computing">distributed environment</a>. The BRE also contains an expression <a href="Parser" class="mw-redirect" title="Parser">parser</a> that automatically performs simple operations to minimize the amount of code required to be manually implemented in the component.

The <a href="Implementation_(computing)" class="mw-redirect" title="Implementation (computing)">implementation</a> of components is supported by views that are automatically able to be extracted from the DBT. These views provide the component behavior trees (CRTs) of individual components, along with their interfaces. This information, together with the information in the integrated composition tree (ICT) captured about each component, provides the information needed to implement each component.

Several BREs can be linked together to form complex systems using a system-of-systems construct and the Behavior Engineering Component Integration Environment (BECIE). BECIE is also used to monitor and control the behavior tree models being executed within a BRE, similar to <a href="SCADA" title="SCADA">supervisory control and data acquisition (SCADA)</a> systems used in industrial process control.

Executable behavior trees have been developed for case studies<a href="#cite_note-shuttle04-22">[22]</a> including automated train protection, <a href="#cite_note-integratingSoftHard08-32">[32]</a> mobile robots with a dynamic object following, an ambulatory infusion pump,<a href="#cite_note-integratingSafety05-20">[20]</a> and traffic light management systems. A version of the BRE suited for embedded systems (eBRE) is also available, with reduced functionality tailored for small-footprint microcontrollers.

<div class="mw-heading mw-heading2"><h2 id="Applications">Applications</h2></div>

Behavior tree modeling can and has been applied to a diverse range of applications over a number of years. Some of the main application areas are described below.

<div class="mw-heading mw-heading3"><h3 id="Large-scale_systems">Large-scale systems</h3></div>

Modeling large-scale systems with extensive sets of natural-language requirements has always been a major focus for testing behavior trees and the overall behavior engineering process. Conducting these evaluations and trials of the method has involved work with a number of industry partners and government departments in Australia. The systems studied have included a significant number of defense systems, enterprise systems, transportation systems, information systems, health systems, and sophisticated control systems with stringent safety requirements. The results of these studies have all been classified as commercial-in-confidence. However, the results of the extensive industry trials<a href="#cite_note-raytheonSysResearch-3">[3]</a><a href="#cite_note-raytheonAustJoint-4">[4]</a> with <a href="Raytheon" title="Raytheon">Raytheon</a> Australia are presented below in the Industry Section. This work has shown that translating requirements into integrated static and dynamic behavior-tree views revealed substantially more major defects than the company’s standard review processes detected.<a href="#cite_note-industryTrialsPaper-33">[33]</a>

<div class="mw-heading mw-heading3"><h3 id="Embedded_systems">Embedded systems</h3></div>

Failure of a design to meet a system's requirements can result in schedule and cost overruns.<a href="#cite_note-34">[34]</a> If there are also critical dependability issues, not satisfying system requirements can have life-threatening consequences.<a href="#cite_note-35">[35]</a> However, in current approaches, ensuring that requirements are met is often delayed until late in the development process, during a cycle of testing and debugging..<a href="#cite_note-36">[36]</a> This work describes how the system development approach, behavior engineering, can be used to develop software for <a href="Embedded_system" title="Embedded system">embedded systems</a>.<a href="#cite_note-embeddedSys05-27">[27]</a> The result is a model-driven development approach that creates embedded system software meeting its requirements through the application of the development process.

<div class="mw-heading mw-heading3"><h3 id="Hardware_–_software_systems">Hardware – software systems</h3></div>

Many large-scale systems consist of a mixture of co-dependent software and hardware. The different nature of software and hardware means they’re often modeled separately using different approaches. This can subsequently lead to integration problems due to incompatible assumptions about hardware/software interactions.<a href="#cite_note-integratingSoftHard08-32">[32]</a> These problems can be overcome by integrating behavior trees with the <a href="Modelica" title="Modelica">Modelica</a> <a href="Mathematical_modelling" class="mw-redirect" title="Mathematical modelling">mathematical modeling</a> approach.<a href="#cite_note-integratingSoftHard08-32">[32]</a> The environment and hardware components are modeled using Modelica and integrated with an executable software model that uses behavior trees.

<div class="mw-heading mw-heading3"><h3 id="Role-based_access_control">Role-based access control</h3></div>

To ensure correct implementation of complex <a href="Access_control" title="Access control">access control</a> requirements, it is important that the validated and verified requirements are effectively integrated with the rest of the system.<a href="#cite_note-earlyValidation07-37">[37]</a> It is also important that the system can be validated and verified early in the development process. An integrated, role-based access control model has been developed.<a href="#cite_note-verifValid06-38">[38]</a> The model is based on the graphical behavior tree notation and can be validated by <a href="Simulation" title="Simulation">simulation</a>, as well as verified using a <a href="Model_checker" class="mw-redirect" title="Model checker">model checker</a>. Using this model, access control requirements can be integrated with the rest of the system from the outset, because: a single notation is used to express both access control and <a href="Functional_requirements" class="mw-redirect" title="Functional requirements">functional requirements</a>; a systematic and incremental approach to constructing a formal behavior tree specification can be adopted; and the specification can be simulated and model checked. The effectiveness of the model has been evaluated using a case study with distributed access control requirements.<a href="#cite_note-earlyValidation07-37">[37]</a>

<div class="mw-heading mw-heading3"><h3 id="Biological_systems">Biological systems</h3></div>

Because behavior trees describe complex behavior, they can be used for describing a range of systems not limited to those that are computer-based.<a href="#cite_note-contracts02-39">[39]</a> In a biological context, behavior trees can be used to piece together a procedural interpretation of biological functions described in research papers, treating the papers as the requirements documents as described above. This can help to construct a more concrete description of the process than is possible from reading only and can also be used as the basis for comparing competing theories in alternative papers. In ongoing research, the behavior tree notation is being used to develop models of the brain function in rats under <a href="Fear_conditioning" title="Fear conditioning">fear conditioning</a>.

<div class="mw-heading mw-heading3"><h3 id="Game_AI_modeling">Game AI modeling</h3></div>

<div role="note" class="hatnote navigation-not-searchable">Main article: <a href="Behavior_tree_(artificial_intelligence%2C_robotics_and_control)" title="Behavior tree (artificial intelligence, robotics and control)">Behavior tree (artificial intelligence, robotics and control)</a></div>

While behavior trees have become popular for modeling the <a href="Artificial_intelligence" title="Artificial intelligence">artificial intelligence</a> in computer games such as <a href="Halo_(franchise)" title="Halo (franchise)">Halo</a><a href="#cite_note-HaloBT-40">[40]</a> and <a href="Spore_(2008_video_game)" title="Spore (2008 video game)">Spore</a>,<a href="#cite_note-sporeBT-41">[41]</a> these types of trees are very different from the ones described on this page and are closer to a combination of hierarchical <a href="Finite-state_machine" title="Finite-state machine">finite-state machines</a> or <a href="Decision_trees" class="mw-redirect" title="Decision trees">decision trees</a>. Soccer-player modeling has also been a successful application of behavior trees.<a href="#cite_note-SoccerBT-42">[42]</a><a href="#cite_note-HoshinoBT-43">[43]</a>

<div class="mw-heading mw-heading3"><h3 id="Model-Based_Testing">Model-Based Testing</h3></div>

<a href="Model-based_testing" title="Model-based testing">Model-based testing</a> is an approach to software testing that requires testers to create test models from requirements of Software Under Test (SUT). Traditionally, modeling languages such as UML statecharts, finite-state machines (FSMs), extended finite-state machines (EFSMs), and flowcharts have been used. Recently, an interesting approach in which Event-Driven Swim Lane Petri Net (EDSLPN) is used as the modeling language also appeared. Behavior tree notation should be considered as a good modeling notation to MBT also, and it has a few advantages among other notations:

<ol><li>It has the same expressiveness level as UML state charts and EDSLPN.</li>

<li>It is intuitive to use as a modeling notation due to its graphical nature.</li>

<li>Each behavior tree node has a requirement tag; these greatly facilitate the creation of a traceability matrix from requirement to test artifact.<a href="#cite_note-44">[44]</a></li></ol>

<div class="mw-heading mw-heading2"><h2 id="Scalability_and_industry_applications">Scalability and industry applications</h2></div>

The first industry trials to test the feasibility of the method and refine its capability were conducted in 2002. Over the last three years, a number of systematic industry trials on large-scale defense, transportation, and enterprise systems have been conducted.<a href="#cite_note-raytheonSysResearch-3">[3]</a><a href="#cite_note-industryTrialsPaper-33">[33]</a> This work has established that the method scales to systems with large numbers of requirements but also that it is important to use tool support<a href="#cite_note-Integrare07-23">[23]</a><a href="#cite_note-RaytheonAswec08-45">[45]</a> in order to efficiently navigate and edit the resultant large integrated views of graphical data. On average, over a number of projects, 130 confirmed major defects per 1000 requirements have consistently been found after normal reviews and corrections have been made.<a href="#cite_note-industryTrialsPaper-33">[33]</a> With less mature requirements sets, much higher defect rates have been observed.

An important part of this work with industry has involved applying the analysis part of the method to six large-scale defense projects for <a href="Raytheon" title="Raytheon">Raytheon</a> Australia. They see the method as "a key risk mitigation strategy, of use in both solution development and as a means of advising the customer on problems with acquisition documentation".<a href="#cite_note-boston08-46">[46]</a><a href="#cite_note-47">[47]</a> An outcome of these industry trials has been the joint development<a href="#cite_note-raytheonAustJoint-4">[4]</a> with Raytheon Australia of an industry-strength tool to support the analysis, editing, and display of large integrated sets of requirements.<a href="#cite_note-RaytheonAswec08-45">[45]</a> More extensive details of industry findings can be found on the Behavior Engineering website.<a href="#cite_note-BEWebsite-48">[48]</a>

Dr. Terry Stevenson (chief technical officer, Raytheon Australia), Mr. Jim Boston (senior project manager, Raytheon Australia), Mr. Adrian Pitman from the <a href="Defence_Materiel_Organisation" class="mw-redirect" title="Defence Materiel Organisation">Australian Defense Materiel Organization</a>, Dr. Kelvin Ross (CEO, K.J. Ross & Associates), and Christine Cornish (Bushell & Cornish) have provided the special opportunities needed to support this research and to conduct the industry trials<a href="#cite_note-raytheonSysResearch-3">[3]</a><a href="#cite_note-industryTrialsPaper-33">[33]</a> and live project work. This work has been supported by the <a href="Australian_Research_Council" title="Australian Research Council">Australian Research Council</a> – <a href="ARC_Centre_for_Complex_Systems" title="ARC Centre for Complex Systems">ARC Centre for Complex Systems</a> and funds received from industry.<a href="#cite_note-49">[49]</a>

<div class="mw-heading mw-heading2"><h2 id="Advantages">Advantages</h2></div>

As a behavior modeling representation, behavior trees have a number of significant benefits and advantages:

<ul><li>They employ a well-defined and effective strategy for dealing with requirement complexity, particularly where the initial needs of a system are expressed using hundreds or thousands of requirements written in natural language. This significantly reduces the risk on large-scale projects.<a href="#cite_note-industryTrialsPaper-33">[33]</a></li>

<li>By rigorously translating then integrating requirements at the earliest possible time, they provide a more effective means for uncovering requirement defects than competing methods.<a href="#cite_note-industryTrialsPaper-33">[33]</a><a href="#cite_note-boston08-46">[46]</a></li>

<li>They employ a single, simple notation<a href="#cite_note-BTNotation-16">[16]</a> for <a href="Analysis" title="Analysis">analysis</a>, <a href="Specification_(computing)" class="mw-redirect" title="Specification (computing)">specification</a>, and to represent the behavior design of a system.</li>

<li>They represent the system behavior as an executable integrated whole.</li>

<li>They build the behavior of a system out of its <a href="Functional_requirements" class="mw-redirect" title="Functional requirements">functional requirements</a> in a directly traceable way, which aids <a href="Verification_and_validation" title="Verification and validation">verification and validation</a>.<a href="#cite_note-Integrare07-23">[23]</a><a href="#cite_note-verifValid06-38">[38]</a></li>

<li>They can be understood by <a href="Stakeholder_(corporate)" title="Stakeholder (corporate)">stakeholders</a> without the need for <a href="Formal_methods" title="Formal methods">formal methods</a> training. By strictly retaining the vocabulary of the original requirements, this eases the burden of understanding.</li>

<li>They have a <a href="Semantics_of_programming_languages" class="mw-redirect" title="Semantics of programming languages">formal semantics</a>,<a href="#cite_note-colvinHayesNotation-18">[18]</a> they support <a href="Concurrency_(computer_science)" title="Concurrency (computer science)">concurrency</a>, they are <a href="Executable" title="Executable">executable</a>, and they can be <a href="Simulated" class="mw-redirect" title="Simulated">simulated</a>, <a href="Model_checking" title="Model checking">model checked</a>, and used to undertake <a href="Failure_mode_and_effects_analysis" title="Failure mode and effects analysis">failure mode and effects analysis</a>.<a href="#cite_note-automatedFailEffect05-19">[19]</a></li>

<li>They can be used equally well to model human processes, to analyze contracts,<a href="#cite_note-contracts02-39">[39]</a> to represent forensic information, to represent biological systems, and many other applications. In each case, they deliver the same benefits in terms of managing complexity and seeing things as a whole. They can also be used for <a href="Safety-critical_system" title="Safety-critical system">safety critical systems</a>,<a href="#cite_note-integratingSafety05-20">[20]</a> <a href="Embedded_system" title="Embedded system">embedded systems</a>,<a href="#cite_note-embeddedSys05-27">[27]</a> and <a href="Real-time_systems" class="mw-redirect" title="Real-time systems">real-time systems</a>.<a href="#cite_note-realTimeCollab05-50">[50]</a><a href="#cite_note-dataflowContstraint06-51">[51]</a><a href="#cite_note-timeBT07-52">[52]</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="Disadvantages">Disadvantages</h2></div>

<ul><li>For small textbook-level examples, their tree-like nature means that the graphic models produced are sometimes not as compact as the <a href="State_diagram" title="State diagram">state diagram</a> or <a href="State_machine" class="mw-redirect" title="State machine">state machine</a> behavior specifications.</li>

<li>Tool support is needed to navigate the huge integrated behavior trees for systems that have hundreds or thousands of requirements.</li>

<li>Presentation to a large group can be difficult, given the inherent size of a complicated system's tree.</li>

<li>There is a need to provide additional sophisticated tool support to fully exploit integrated behavior tree models.</li></ul>

<ul><li><a href="Behavioral_engineering" class="mw-redirect" title="Behavioral engineering">Behavioral engineering</a></li>

<li><a href="Modeling_language" title="Modeling language">Modeling language</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .reflist{margin-bottom:0.5em;list-style-type:decimal}@media screen{.mw-parser-output .reflist{font-size:90%}}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}

/* end https://en.wikipedia.org/ */

</style><div class="reflist">

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><cite id="CITEREFLindsay2010" class="citation book cs1">Lindsay, Peter A. (1 September 2010). <a rel="nofollow" class="external text" href="https://doi.org/10.1109/sefm.2010.11">"Behavior Trees: From Systems Engineering to Software Engineering"</a>. 2010 8th IEEE International Conference on Software Engineering and Formal Methods. IEEE. pp. 21–30. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1109%2Fsefm.2010.11">10.1109/sefm.2010.11</a>. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-1-4244-8289-4</bdi>.</cite>

</li>

<li id="cite_note-dromey07EngLgeScale-2">^ <a href="#cite_ref-dromey07EngLgeScale_2-0">a</a> <a href="#cite_ref-dromey07EngLgeScale_2-1">b</a> <a href="#cite_ref-dromey07EngLgeScale_2-2">c</a> Dromey, R.G. 2007. <a rel="nofollow" class="external text" href="http://www.beworld.org/BE/resource/presentation/Eng-LargeScale-Systems.pdf">Principles for Engineering Large-Scale Software-Intensive Systems</a>

</li>

<li id="cite_note-raytheonSysResearch-3">^ <a href="#cite_ref-raytheonSysResearch_3-0">a</a> <a href="#cite_ref-raytheonSysResearch_3-1">b</a> <a href="#cite_ref-raytheonSysResearch_3-2">c</a> <a href="#cite_ref-raytheonSysResearch_3-3">d</a> Boston, J. 2008. <a rel="nofollow" class="external text" href="http://www.raytheon.com.au/Default.aspx?x=501">Raytheon Australia supports pioneering systems research</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20090915050723/http://www.raytheon.com.au/Default.aspx?x=501">Archived</a> 15 September 2009 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>

</li>

<li id="cite_note-raytheonAustJoint-4">^ <a href="#cite_ref-raytheonAustJoint_4-0">a</a> <a href="#cite_ref-raytheonAustJoint_4-1">b</a> <a href="#cite_ref-raytheonAustJoint_4-2">c</a> Raytheon Australia, 2008. <a rel="nofollow" class="external text" href="http://www.raytheon.com.au/Files/Behavior%20Trees.pdf">Understanding grows on Behavior Trees</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20090915050633/http://www.raytheon.com.au/Files/Behavior%20Trees.pdf">Archived</a> 15 September 2009 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>

</li>

<li id="cite_note-dromey03K1-Dromey-5">^ <a href="#cite_ref-dromey03K1-Dromey_5-0">a</a> <a href="#cite_ref-dromey03K1-Dromey_5-1">b</a> <a href="#cite_ref-dromey03K1-Dromey_5-2">c</a> <a href="#cite_ref-dromey03K1-Dromey_5-3">d</a> <a href="#cite_ref-dromey03K1-Dromey_5-4">e</a> R.G.Dromey, <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/publications/dromey/K1-Dromey.pdf">From Requirements to Design: Formalizing the Key Steps</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20110725054005/http://www.behaviorengineering.org/publications/dromey/K1-Dromey.pdf">Archived</a> 25 July 2011 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>, (Invited Keynote Address), SEFM-2003, IEEE International Conference on Software Engineering and Formal Methods, Brisbane, Sept. 2003, pp. 2–11.

</li>

<li id="cite_note-compositionTree-6"><a href="#cite_ref-compositionTree_6-0">^</a> Behavior Engineering. <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/index.php?option=com_content&task=view&id=24&Itemid=34">Composition Trees</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20090302063932/http://www.behaviorengineering.org/index.php?option=com_content&task=view&id=24&Itemid=34">Archived</a> 2 March 2009 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>

</li>

<li id="cite_note-winters-7"><a href="#cite_ref-winters_7-0">^</a> Winter, K. 2007. <a rel="nofollow" class="external text" href="http://espace.library.uq.edu.au/eserv/UQ:100586/Formalising_behaviour_trees_with_csp.pdf">Formalising Behaviour Trees with CSP</a>

</li>

<li id="cite_note-dromey06FormalizingTrans-8">^ <a href="#cite_ref-dromey06FormalizingTrans_8-0">a</a> <a href="#cite_ref-dromey06FormalizingTrans_8-1">b</a> R.G.Dromey, <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/publications/dromey/Dromey-Chapter-Final-20051.pdf">"Formalizing the Transition from Requirements to Design"</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20110725053952/http://www.behaviorengineering.org/publications/dromey/Dromey-Chapter-Final-20051.pdf">Archived</a> 25 July 2011 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>, in "Mathematical Frameworks for Component Software – Models for Analysis and Synthesis", Jifeng He, and Zhiming Liu (Eds.), World Scientific Series on Component-Based Development, pp. 156–187, (Invited Chapter) (2006)

</li>

<li id="cite_note-9"><a href="#cite_ref-9">^</a> R.L.Glass, <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/publications/Bob-Glass-GSE-CACM.pdf">"Is This a Revolutionary Idea or Not"</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20110725054100/http://www.behaviorengineering.org/publications/Bob-Glass-GSE-CACM.pdf">Archived</a> 25 July 2011 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>, Communications of the ACM, Vol. 47(11), pp. 23–25, Nov. 2004.

</li>

<li id="cite_note-10"><a href="#cite_ref-10">^</a> R.G.Dromey, <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/publications/dromey/Dromey.pdf">"Climbing Over the ‘No Silver Bullet’ Brick Wall"</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20110725054117/http://www.behaviorengineering.org/publications/dromey/Dromey.pdf">Archived</a> 25 July 2011 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>, IEEE Software, Vol. 23, No. 2, pp. 118–120, (March 2006)

</li>

<li id="cite_note-11"><a href="#cite_ref-11">^</a> R.G.Dromey, Genetic Software Engineering – Simplifying Design Using Requirements Integration, IEEE Working Conference on Complex and Dynamic Systems Architecture, Brisbane, Dec 2001.

</li>

<li id="cite_note-12"><a href="#cite_ref-12">^</a> A. Woolfson, Life Without Genes, Flamingo, 2000, <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>0-00-255618-9</bdi>

</li>

<li id="cite_note-Vico-13"><a href="#cite_ref-Vico_13-0">^</a> Berlin, I. The Crooked Timber of Humanity: Chapters in the History of Ideas, Ed., H.Hardy, Princeton University Press, 1998 <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>0-691-05838-5</bdi>

</li>

<li id="cite_note-14"><a href="#cite_ref-14">^</a> <cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://www.beworld.org/BE/home/history-of-behavior-engineering/">"Behavior Engineering World » History of Behavior Engineering"</a>. Retrieved 24 May 2025.</cite>

</li>

<li id="cite_note-probTimedBTs-15"><a href="#cite_ref-probTimedBTs_15-0">^</a> Colvin, R., Grunske, L., Winter, K. 2007 <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/publications/grunske/IFM1.pdf">Probabilistic Timed Behavior Trees</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20110725054158/http://www.behaviorengineering.org/publications/grunske/IFM1.pdf">Archived</a> 25 July 2011 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>

</li>

<li id="cite_note-BTNotation-16">^ <a href="#cite_ref-BTNotation_16-0">a</a> <a href="#cite_ref-BTNotation_16-1">b</a> <a href="#cite_ref-BTNotation_16-2">c</a> <a href="#cite_ref-BTNotation_16-3">d</a> Behavior Tree Group, <a href="ARC_Centre_for_Complex_Systems" title="ARC Centre for Complex Systems">ARC Centre for Complex Systems</a>, 2007. <a rel="nofollow" class="external text" href="https://projects.ui.ac.id/attachments/download/300/Behavior-Tree-Notation-1.0.pdf">Behavior Tree Notation v1.0 (2007) </a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20160304003828/https://projects.ui.ac.id/attachments/download/300/Behavior-Tree-Notation-1.0.pdf">Archived</a> 2016-03-04 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>

</li>

<li id="cite_note-geneticDesign05-17"><a href="#cite_ref-geneticDesign05_17-0">^</a> Dromey, R.G. <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/publications/dromey/Dromey-LNCS-Final2-new.pdf">"Genetic Design: Amplifying Our Ability to Deal With Requirements Complexity"</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20110725054508/http://www.behaviorengineering.org/publications/dromey/Dromey-LNCS-Final2-new.pdf">Archived</a> 25 July 2011 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>, in S.Leue, and T.J. Systra, Scenarios, Lecture Notes in Computer Science, LNCS 3466, pp. 95–108, 2005.

</li>

<li id="cite_note-colvinHayesNotation-18">^ <a href="#cite_ref-colvinHayesNotation_18-0">a</a> <a href="#cite_ref-colvinHayesNotation_18-1">b</a> <a href="#cite_ref-colvinHayesNotation_18-2">c</a> Colvin, R., Hayes, I.J. 2006 <a rel="nofollow" class="external text" href="http://www.accs.uq.edu.au/documents/TechnicalReports/ACCS_TR_07_01.pdf">A Semantics for Behavior Trees</a>

</li>

<li id="cite_note-automatedFailEffect05-19">^ <a href="#cite_ref-automatedFailEffect05_19-0">a</a> <a href="#cite_ref-automatedFailEffect05_19-1">b</a> <a href="#cite_ref-automatedFailEffect05_19-2">c</a> <a href="#cite_ref-automatedFailEffect05_19-3">d</a> L.Grunske, P.Lindsay, N.Yatapanage, K.Winter, <a rel="nofollow" class="external text" href="https://doi.org/10.1007%2F11589976_9">An Automated Failure Mode and Effect Analysis Based on High-Level Design Specification with Behavior Trees</a>, Fifth International Conference on Integrated Formal Methods (IFM-2005), Eindoven, The Netherlands, 2005.

</li>

<li id="cite_note-integratingSafety05-20">^ <a href="#cite_ref-integratingSafety05_20-0">a</a> <a href="#cite_ref-integratingSafety05_20-1">b</a> <a href="#cite_ref-integratingSafety05_20-2">c</a> Zafar, S. and Dromey, R. G., (2005), <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/publications/dromey/Zafar-IntegratingRequirments.pdf">Integrating Safety and Security Requirements into Design of an Embedded System.</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20110725054345/http://www.behaviorengineering.org/publications/dromey/Zafar-IntegratingRequirments.pdf">Archived</a> 25 July 2011 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a> Asia-Pacific Software Engineering Conference 2005, 15–17 December, Taipei, Taiwan. IEEE Computer Society Press. pp. 629–636.

</li>

<li id="cite_note-buildEnv04-21">^ <a href="#cite_ref-buildEnv04_21-0">a</a> <a href="#cite_ref-buildEnv04_21-1">b</a> Smith, C., Winter, K., Hayes, I., Dromey, R.G., Lindsay, P., Carrington, D.: <a rel="nofollow" class="external text" href="https://ieeexplore.ieee.org/document/1342775">An Environment for Building a System Out of Its Requirements</a>, 19th IEEE International Conference on Automated Software Engineering, Linz, Austria, Sept. (2004).

</li>

<li id="cite_note-shuttle04-22">^ <a href="#cite_ref-shuttle04_22-0">a</a> <a href="#cite_ref-shuttle04_22-1">b</a> Dromey, R.G. <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/publications/dromey/Dromey-SCESM-2004N.pdf">Using Behavior Trees to Model the Autonomous Shuttle System</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20110725054354/http://www.behaviorengineering.org/publications/dromey/Dromey-SCESM-2004N.pdf">Archived</a> 25 July 2011 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>, 3rd International Workshop on Scenarios and State Machines: Models, Algorithms, and Tools (SCESM04) ICSE Workshop W5S, Edinburgh, 25 May 2004

</li>

<li id="cite_note-Integrare07-23">^ <a href="#cite_ref-Integrare07_23-0">a</a> <a href="#cite_ref-Integrare07_23-1">b</a> <a href="#cite_ref-Integrare07_23-2">c</a> L.Wen, R.Colvin, K.Lin, J.Seagrott, N.Yatapanage, R.G.Dromey, 2007, <a rel="nofollow" class="external text" href="http://www98.griffith.edu.au/dspace/bitstream/10072/18625/1/43991_1.pdf">"Integrare, a Collaborative Environment for Behavior-Oriented Design"</a>, in Proceedings of the Fourth International Conference on Cooperative Design, Visualization and Engineering, LNCS 4674, pp. 122–131, 2007

</li>

<li id="cite_note-realTimeColloab06-24"><a href="#cite_ref-realTimeColloab06_24-0">^</a> C. Sun, S. Xia, D. Sun, D. Chen. H.F. Shen, W. Cai: <a rel="nofollow" class="external text" href="http://portal.acm.org/citation.cfm?doid=1188816.1188821">"Transparent adaptation of single-user applications for multi-user real-time collaboration"</a>, ACM Transactions on Computer-Human Interaction, Vol. 13, No.4, December 2006, pp. 531–582.

</li>

<li id="cite_note-SAL2-25"><a href="#cite_ref-SAL2_25-0">^</a> Bensalem, S., Ganesh, V., Lakhnech, Y., Muñoz, C., Owre, et al.: "An Overview of SAL", Fifth NASA Langley Formal Methods Workshop (LFM 2000), 2000, pp. 187–196.

</li>

<li id="cite_note-26"><a href="#cite_ref-26">^</a> Rushby, J. <a rel="nofollow" class="external text" href="http://fm.csl.sri.com/AFM06/slides/Rushby-intro-tutorial.pdf">Automated Formal Methods 2006</a> AFM-2006, Automated Formal Methods 2006, Seattle, August 2006, pp. 6–7.

</li>

<li id="cite_note-embeddedSys05-27">^ <a href="#cite_ref-embeddedSys05_27-0">a</a> <a href="#cite_ref-embeddedSys05_27-1">b</a> <a href="#cite_ref-embeddedSys05_27-2">c</a> Zafar, S. and Dromey, R. G., 2005. <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/publications/dromey/Zafar-SETE2005-ManagingComplexity.pdf">Managing Complexity in Modelling Embedded Systems.</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20110725054400/http://www.behaviorengineering.org/publications/dromey/Zafar-SETE2005-ManagingComplexity.pdf">Archived</a> 25 July 2011 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a> Systems Engineering/Test and Evaluation Conference 2005, 7–9 November, Brisbane, Australia

</li>

<li id="cite_note-probabilistic07-28"><a href="#cite_ref-probabilistic07_28-0">^</a> Grunske, L., Colvin, R., Winter, K. Probabilistic Model-Checking Support for FMEA Quantitative Evaluation of Systems. QEST 2007. Fourth International Conference on the Quantitative Evaluation of Systems, 17-19 Sept. 2007 pp. 119–128

</li>

<li id="cite_note-dromey07FormalPath-29"><a href="#cite_ref-dromey07FormalPath_29-0">^</a> Wen, L., Dromey, R.G. 2007. <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/images/publications/wen_l_dromey_r_g_gse_change.pdf">From Requirements Change to Design Change: A Formal Path</a>

</li>

<li id="cite_note-30"><a href="#cite_ref-30">^</a> Wen, L., Dromey, R.G. 2005. <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/publications/wen/journal.pdf">Architecture Normalization for Component-Based Systems</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20110725054411/http://www.behaviorengineering.org/publications/wen/journal.pdf">Archived</a> 25 July 2011 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a> Proceedings of the 2nd International Workshop on Formal Aspects of Component Software FACS'05, pp. 247–261.

</li>

<li id="cite_note-middleware-31"><a href="#cite_ref-middleware_31-0">^</a> RTI Inc. 2007 "Meeting Real-Time Requirements in Integrated Defense Systems", <a rel="nofollow" class="external text" href="http://www.rti.com/mk/defense_systems.html">RTI White Paper</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20080920033015/http://www.rti.com/mk/defense_systems.html">Archived</a> 20 September 2008 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>.

</li>

<li id="cite_note-integratingSoftHard08-32">^ <a href="#cite_ref-integratingSoftHard08_32-0">a</a> <a href="#cite_ref-integratingSoftHard08_32-1">b</a> <a href="#cite_ref-integratingSoftHard08_32-2">c</a> Myers, T., Fritzson, P., Dromey, R.G. 2008. <a rel="nofollow" class="external text" href="http://www.ida.liu.se/~petfr/paperlinks/2008-07-Myers-Fritzson-Dromey-EOOLT2008-HardwareSoftwareModeling.pdf">Seamlessly Integrating Software & Hardware Modelling for Large-Scale Systems.</a> 2nd International Workshop on Equation-Based Object-Oriented Languages and Tools (EOOLT 2008), Cyprus, July 2008. pp. 5–15.

</li>

<li id="cite_note-industryTrialsPaper-33">^ <a href="#cite_ref-industryTrialsPaper_33-0">a</a> <a href="#cite_ref-industryTrialsPaper_33-1">b</a> <a href="#cite_ref-industryTrialsPaper_33-2">c</a> <a href="#cite_ref-industryTrialsPaper_33-3">d</a> <a href="#cite_ref-industryTrialsPaper_33-4">e</a> <a href="#cite_ref-industryTrialsPaper_33-5">f</a> Powell, D. 2007. <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/docs/ASWEC07_Industry_Powell.pdf">Requirements Evaluation Using Behavior Trees – Findings from Industry</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20110725061927/http://www.behaviorengineering.org/docs/ASWEC07_Industry_Powell.pdf">Archived</a> 25 July 2011 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>

</li>

<li id="cite_note-34"><a href="#cite_ref-34">^</a> Barker, D. 2000. <a rel="nofollow" class="external text" href="https://ieeexplore.ieee.org/document/890177">Requirements modeling technology: a vision for better, faster, and cheaper systems.</a> Proceedings from VHDL International Users Forum Fall Workshop, 2000. pp. 3–6.

</li>

<li id="cite_note-35"><a href="#cite_ref-35">^</a> Leveson, N. G. Safeware: System Safety and Computers: [a guide to preventing accidents and losses caused by technology]. Addison-Wesley Publishing Company, 1995. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>0-201-11972-2</bdi>

</li>

<li id="cite_note-36"><a href="#cite_ref-36">^</a> Futrell, R. T., Shafer, D.F., Shafer, L.I. Quality Software Project Management (Software Quality Institute Series). Prentice Hall, 2002 <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>0-13-091297-2</bdi>

</li>

<li id="cite_note-earlyValidation07-37">^ <a href="#cite_ref-earlyValidation07_37-0">a</a> <a href="#cite_ref-earlyValidation07_37-1">b</a> Zafar, S. Colvin, R., Winter, K., Yatapanage, N., Dromey, R.G. <a rel="nofollow" class="external text" href="https://ieeexplore.ieee.org/document/4425884">Early Validation and Verification of a Distributed Role-Based Access Control Model.</a> 14th Asia-Pacific Software Engineering Conference, Nagoya, Japan, December 2008. pp. 430–437.

</li>

<li id="cite_note-verifValid06-38">^ <a href="#cite_ref-verifValid06_38-0">a</a> <a href="#cite_ref-verifValid06_38-1">b</a> Zafar, S., K.Winter, R.Colvin, R.G.Dromey, <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/publications/dromey/Zafar_Integrated_BTRBAC.pdf">"Verification of an Integrated Role-Based Access Control Model"</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20110725061854/http://www.behaviorengineering.org/publications/dromey/Zafar_Integrated_BTRBAC.pdf">Archived</a> 25 July 2011 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>, 1st International Workshop – Asian Working Conference on Verified Software (AWCVS'06), pp 230-240, Macao, Oct. 2006.

</li>

<li id="cite_note-contracts02-39">^ <a href="#cite_ref-contracts02_39-0">a</a> <a href="#cite_ref-contracts02_39-1">b</a> Milosevic, Z., Dromey, R.G. <a rel="nofollow" class="external text" href="https://ieeexplore.ieee.org/document/1137692">On Expressing and Monitoring Behavior in Contracts</a>, EDOC 2002, Proceedings, 6th International Enterprise Distributed Object Computing Conference, Lausanne, Switzerland, Sept. 2002, pp. 3-14.

</li>

<li id="cite_note-HaloBT-40"><a href="#cite_ref-HaloBT_40-0">^</a> Damian Isla <a rel="nofollow" class="external text" href="https://www.gamedeveloper.com/programming/gdc-2005-proceeding-handling-complexity-in-the-i-halo-2-i-ai">Handling Complexity in the Halo 2 AI.</a>

</li>

<li id="cite_note-sporeBT-41"><a href="#cite_ref-sporeBT_41-0">^</a> Chris Hecker <a rel="nofollow" class="external text" href="http://chrishecker.com/My_Liner_Notes_for_Spore/Spore_Behavior_Tree_Docs">My Liner Notes for Spore</a>

</li>

<li id="cite_note-SoccerBT-42"><a href="#cite_ref-SoccerBT_42-0">^</a> Xiao-Wen Terry Liu and Jacky Baltes <a rel="nofollow" class="external text" href="http://www.cs.umanitoba.ca/~jacky/Publications/pdf/liu04:_intuit_flexib_archit_intel_mobil_robot.pdf">An Intuitive and Flexible Architecture for Intelligent Mobile Robots</a> 2nd International Conference on Autonomous Robots and Agents, December 13–15, 2004 Palmerston North, New Zealand

</li>

<li id="cite_note-HoshinoBT-43"><a href="#cite_ref-HoshinoBT_43-0">^</a> Yukiko Hoshino, Tsuyoshi Takagi, Ugo Di Profio, and Masahiro Fujita <a rel="nofollow" class="external text" href="http://web.mit.edu/zoz/Public/ICRA04-Hoshino.pdf">Behavior description and control using behavior module for personal robot</a>

</li>

<li id="cite_note-44"><a href="#cite_ref-44">^</a> <cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://testerhome.com/topics/18850">"A Model Based Testing tool - MBTester · 测试之家"</a>. testerhome.com. Retrieved 12 June 2025.</cite>

</li>

<li id="cite_note-RaytheonAswec08-45">^ <a href="#cite_ref-RaytheonAswec08_45-0">a</a> <a href="#cite_ref-RaytheonAswec08_45-1">b</a> Phillips, V., (Raytheon Australia), <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/images/publications/dromey2/bese_master_v2.ppt">"Implementing a Behavior Tree Analysis Tool Using Eclipse Development Frameworks"</a>, Australian Software Engineering Conference (ASWEC’08), Perth, March 2008

</li>

<li id="cite_note-boston08-46">^ <a href="#cite_ref-boston08_46-0">a</a> <a href="#cite_ref-boston08_46-1">b</a> Boston, J., (Raytheon Australia), <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/images/publications/dromey2/sp8_powerpoint_jim_boston.pdf">Behavior Trees – How they improve Engineering Behaviour?</a>, 6th Annual Software and Systems Engineering Process Group Conference (SEPG 2008), Melbourne, Aug. 2008.

</li>

<li id="cite_note-47"><a href="#cite_ref-47">^</a> McNicholas, D., (Raytheon Australia), 2007. <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/images/publications/dromey2/be-industry-benefits.doc">Behavior Engineering Industry Benefits</a>

</li>

<li id="cite_note-BEWebsite-48"><a href="#cite_ref-BEWebsite_48-0">^</a> Behavior Engineering. <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/">Behavior Engineering website</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20090301170621/http://www.behaviorengineering.org/">Archived</a> 1 March 2009 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>

</li>

<li id="cite_note-49"><a href="#cite_ref-49">^</a> For further details see:

<ul><li><a rel="nofollow" class="external text" href="http://www.raytheon.com.au/Files/Behavior%20Trees.pdf">Raytheon Australia – Behavior Trees Joint Development</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20090915050633/http://www.raytheon.com.au/Files/Behavior%20Trees.pdf">Archived</a> 15 September 2009 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a></li>

<li><a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/images/publications/dromey2/bese_master_v2.ppt">"Implementing a Behavior Tree Analysis Tool Using Eclipse Development Frameworks"</a> Vincent Phillips, Raytheon Australia.</li>

<li><a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/images/publications/dromey2/sp8_powerpoint_jim_boston.pdf">Behavior Trees – How they improve Engineering Behaviour?</a> Jim Boston, Raytheon Australia.</li>

<li><a rel="nofollow" class="external text" href="http://www.raytheon.com.au/Default.aspx?x=501">Raytheon Australia supports pioneering systems research</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20090915050723/http://www.raytheon.com.au/Default.aspx?x=501">Archived</a> 15 September 2009 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a></li></ul>

</li>

<li id="cite_note-realTimeCollab05-50"><a href="#cite_ref-realTimeCollab05_50-0">^</a> Lin, K., Chen, D., Sun, C., Dromey, R.G., <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/publications/kailin/CDVEO5_Kevin.pdf">A Constraint Maintenance Strategy and Applications in real-time Collaborative Environments</a>, 2nd International Conference on Cooperative Design, Visualization and Engineering (CDVE2005), 2005.

</li>

<li id="cite_note-dataflowContstraint06-51"><a href="#cite_ref-dataflowContstraint06_51-0">^</a> Lin, K., Chen, D., Dromey, R.G., Sun, CZ.: <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/publications/kailin/IEEE06_Kevin.pdf">Multi-way Dataflow Constraint Propagation in Real-time Collaborative Systems</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20110725061427/http://www.behaviorengineering.org/publications/kailin/IEEE06_Kevin.pdf">Archived</a> 25 July 2011 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>, IEEE, The 2nd International Conference on Collaborative Computing: Networking, Applications and Worksharing (CollaborateCom 2006), Atlanta, Georgia, USA, Nov, 2006.

</li>

<li id="cite_note-timeBT07-52"><a href="#cite_ref-timeBT07_52-0">^</a> Grunske, L., Winter, K., Colvin, R., <a rel="nofollow" class="external text" href="http://www.behaviorengineering.org/publications/grunske/ASWEC20072.pdf">"Timed Behavior Trees and their application to verifying real-time systems"</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20081118165542/http://www.behaviorengineering.org/publications/grunske/ASWEC20072.pdf">Archived</a> 18 November 2008 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>, Proceedings of 18th Australian Conference on Software Engineering (AEWEC 2007), April 2007, accepted for publication.

</li>

</ol></div></div>

<div class="mw-heading mw-heading2"><h2 id="External_links">External links</h2></div>

<ul><li><a rel="nofollow" class="external text" href="http://www.beworld.org/BE/">Behavior Engineering</a></li>

<li><a rel="nofollow" class="external text" href="https://web.archive.org/web/20110220113558/http://www.raytheon.com.au/rtnwcm/groups/rau/documents/download/rau_factsheets_behaviortrees.pdf">Raytheon Australia supports pioneering systems research</a></li>

<li><a rel="nofollow" class="external text" href="http://www.accs.uq.edu.au/projectsDCS.html">ARC Centre for Complex Systems – ACCS Program: Dependable Complex Computer-Based Systems</a></li>

<li><a rel="nofollow" class="external text" href="http://arc.realviewtechnologies.com/default.aspx?iid=8075&startpage=page0000030&xml=outcomes.xml">Australian Research Council – Outcomes: Taming Complexity</a></li></ul></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2025-08-07" href="https://en.wikipedia.org/wiki/?title=Behavior_tree&oldid=1304648074">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>